I have been using this for a couple days and have not hit any issues in a project with 58 “compilation units”.

The build runner is only responsible to collect information that is directly associated with the build system. All further tasks like tying a file to a build.zig in part of the document store which already implemented with getAssociatedBuildFileUri and uriAssociatedWithBuild to find out whether a file is used by one of it's build system modules. This serves a similar purpose to what has been added to the build runner. This logic should instead be updated to return which module was responsible for the match.

But more importantly, while this PR appears offer better resolution of a root module or similar. It still has an inaccurate view of how compile steps and modules work in the build system. A proper solution should be able to handle these situations:

• a compilation step only has a root module (modules form a graph not a list)
• modules consist of a root source file and can import other modules
• imported modules are not visible their parent module
• a module can be part of multiple compilation steps (may be to complex to support)
• a source file may be part of multiple modules by placing them in different compilation steps (may be to complex to support)

Keep in mind that the build runner code incorrectly uses the name "package" to refer to a "module".

I appreciate the effort that has been put into this but I rather reject this PR until a more complete solution has been implemented. I plan to work on this myself and I would not recommend working on such a comparatively large task to someone who is new to this codebase.